5 Minutes
When I started working at Sparkteams about two years ago, I was enthusiastic about programming. I thought, maybe Functional Programming, Haskell, Strong Type Systems (and many other things) would change how we write software as an industry. If there was only an opportunity to use these things!
At a company dinner, I remember quite vividly, another junior developer and I, boasted how Rust and Haskell can rule out whole classes of bugs! The reaction of our colleagues could at best be described as mildly interested. Back then, I wrote it off as some kind of disillusion, an effect of spending too many years in this industry, writing Java for ’legacy’ applications.
Now, two years later, I think differently. What I quickly dismissed as disillusion is something else. It’s a focus on building things with people. That colleague who figuratively just shrugged at some of these ideas, speaks with great joy about how at one of our customers, a team with inter-personal friction and fluctuation turned into a well-rehearsed, friendly and cooperating team. Similarly, I see how lots of senior folks really focus on shipping things.
Two years in, I’m still a keen proponent of functional programming and other shiny things. Although, I think my zeal mellowed somewhat. Lately I even found myself arguing in favor of some tech that can only be described as boring. In retrospect I think I had case of Shiny Thing Syndrome (I did not make this term up, google it!). Something that seems to be very common among us software developers.
Anyway, back to what I actually wanted to write about: Choosing the right technology for the job. To state the obvious, when we choose to add a technology to our stack, we want to get most bang for our buck. Meaning, that it not only has to solve our problem effectively, but also that the costs throughout its whole lifecycle are low in terms of money and time.
My point is: As your team grows bigger and you collect experience with your current tech stack, adding new technology becomes more and more expensive. Dan McKinley came up with the idea of ‘innovation tokens’, an imaginary currency of which you only have a limited supply and that you have to spend, any time you want to add a new technology to your stack.
Adding MongoDB to your stack? That costs you 2 tokens. Customizing your build process with Gradle? That’s another token. Rewriting your app in Closure? Sorry, can’t do, not enough tokens left. Sounds bleak? It doesn’t need to. You can earn back tokens by cleaning up your stack. Do you really need three different JSON serializers? Unify these and you can earn back one token. Remove that half-baked attempt at implementing another session store? Another token.
Cost in innovation tokens
How do you calculate a technology’s cost in innovation tokens? I tried to come up with a small set of factors that should help.
-
Surface Complexity. Or, how hard is it to understand what that piece is doing? If I can describe what that piece of tech is doing to a new team member in a few sentences and that person can then go on and can then productively use it, I’d say, it has a low surface complexity.
Note that this is not necessarily the whole complexity of the technology. For example, let’s take an image library like ImageMagick. It’s easy to explain what it does, despite the inherent complexity of working with images.
-
Liability. Or, how hard is it to replace the piece with an alternative? This is what makes architectural innovations so expensive.
-
Future-Proof. Or, how likely is it that you have to replace it?
-
Industry-Adoption. Or, How established is this technology? Choosing an established technology is good for you. It makes it easier to hire people proficient in the technology. But even when you’re not looking to grow the team you can profit from treading the beaten path.
Take Spring for example, it’s not shiny, but you can be sure, that every conceivable mistake has already been made and has been discussed on the internet.
Conclusion
These factors that make a technology ‘boring’ cannot be evaluated on their own, they depend on** your industry**, your people and your existing technology stack. And of course, they need to be weighted against the value they bring to the table, e.g. performance or functionality.
In the next blog posts we will present you a few examples of the most ‘boring’ technologies we use with our customers. We will start by having a look at
